System and method for generating driver status and destination arrival  notifications for reducing distracted driving and increasing driver safety

ABSTRACT

System and method for generating notifications when a person is in a driving state, in a non-driving state, and optionally a destination arrival notification so that interested parties, such as family members, friends and/or co-workers, can make informed and proactive decisions to not call or text the person while driving is described. With push notifications, interested parties can thus make informed decisions and purposely delay making a phone call or texting a driver until after they have arrived at their destination and are no longer driving. As a result, drivers are not needlessly distracted, significantly improving road safety.

RELATED APPLICATIONS

This application is a continuation of prior, co-pending U.S. applicationSer. No. 15/825,024, filed Nov. 28, 2017, which is a continuation ofU.S. application Ser. No. 15/390,608, filed on Dec. 26, 2016, (now U.S.Pat. No. 9,848,308) which claims the benefit of priority under 35 U.S.C.§ 119 (e) to U.S. Provisional Application No. 62/275,244, filed Jan. 6,2016 entitled “Hardware free Geo-Location based in-drive status and pusharrival notification for driver safety,” all of which are incorporatedby reference herein for all purposes.

BACKGROUND Field of the Invention

This invention relates to a system and method for generating anddelivering driver status and destination arrival notifications, and moreparticularly, to generating for a driver an in-driving statenotification, a not driving state notification and optionally adestination arrival notification for distribution to interested parties,such as family members, friends and/or co-workers. In response to thenotifications, recipients can make an informed and proactive decision tonot call or text the person while driving, resulting reduced incidencesof distracted driving and increased road safety.

Description of Related Art

With the proliferation of mobile devices such as wireless telephones,smart phones, tablets and wearable Internet-connected computing devices,such as smart-watches, more and more people are communicating while onthe go. For example, many automobile drivers will often engage intelephone conversations or text while driving. The danger of engaging insuch behavior is well documented. Distracted drivers are at asignificantly increased risk of causing an accident, often resulting indeath, injury and/or property damage to themselves and/or others.

The problem of distracted driving is often exacerbated by familymembers, friends, co-workers, supervisors or others simply because theydo not know that a person they wish to communicate with is driving. Forexample, a parent may text or call their son or daughter, un-aware thathe or she may be driving. Similarly, a fleet manager or dispatcher maycall or text an employee, again un-aware that the employee is driving.In either case, the driver will be distracted by the incoming phone callor text, particularly if they elect to participate in the phone call orread and/or respond to the text while driving. As a result, theordinarily innocuous act of calling or texting may be unknowinglycreating a dangerous situation for loved ones, friends, and/or workcolleagues if the person happens to be driving when contacted.

A system and method for generating driver status and destination arrivalpush notifications, distributed to interested parties such as familymembers, friends, work colleagues and/or others, is therefore needed.

SUMMARY OF THE INVENTION

The above-described problems are solved by a system and method forgenerating driver status and destination arrival push notifications, andmore particularly, to generating notifications when a person is in adriving state, in a non-driving state, and optionally a destinationarrival notification so that interested parties, such as family members,friends and/or co-workers, can make informed and proactive decisions tonot call or text the person while driving. The present invention thusprovides a unique and novel approach to presenting timely “peace ofmind” safety information regarding the driving status of a person tointerested parties, previously not possible. For example, parents can benotified when a child is driving or is in a vehicle or a fleet managercan be notified when an employee is driving. In either case, thenotified party can purposely delay making a phone call or texting theperson until after they have arrived at their destination and are nolonger driving. As a result, the person is not needlessly distractedwhile driving, significantly improving road safety.

In one non-exclusive embodiment, the system and method involves the useof an application or “app” installed on a mobile device (e.g., a mobilephone or tablet computer) belonging to a person. The app silently runs abackground process, determining when the mobile device is in a vehiclethat is traveling over a road surface or not. When such a drivingdetermination is made, an in-driving notice is generated by the app andwirelessly sent to a cloud computing infrastructure. Within the cloudinfrastructure, a push notification is generated and is sent to one ormore target recipients associated with the person. Alternatively, whenthe app determines that mobile device is no longer in a driving state, anot driving notice is generated and delivered to the cloud. In response,the cloud infrastructure generates and delivers to the target recipientsa non-driving state notification. In various embodiments, the pushnotifications can be sent to the target recipients via a message (e.g.,text, SMS, voice, email, etc.) or by updating one or more dashboard(s)that is/are accessible by the one or more target recipient(s)respectively.

In an alternative embodiment, the in driving or not drivingnotifications may optionally each include a date and time stamp.

In yet another alternative embodiment, the app may operate incooperation with Location Services (e.g., GPS) functionality to providea start geographic location when the in driving state is detected and anend geographic location when the non-driving state is detected. Withstart and end locations, the entire trip of the driver can be tracked,mapped and provided to interested parties, a feature many parents andfleet managers will find highly useful. In one variation of thisembodiment, the driver's current location can also be provided bymapping a longitude/latitude location via maps (i.e. Google® Maps) onthe interested parties mobile device. As an alternative to utilizinglocations services to determine the start and end of a trip, the app mayoperate in cooperation with the OnBoard Diagnostic (OBD) system of thevehicle in determining the in driving status, and the non-driving statusof the vehicle. In yet other embodiments, a location of a driver may bediscerned by triangulating their phone's location to cell towers and/orwi-fi networks.

In yet another embodiment, the cloud computing architect can operate incooperation with other cloud computing/communication domains and providepresence information (i.e., in driving, not driving states) of amultiplicity of drivers across one or multiple communication platforms.By providing such information regarding the current driving status of alarge number of drivers across one or multiple platforms (e.g., What'sApp®, Viber®, Skype® etc.), the driver status can become almostuniversally known. Family members, friends, work colleagues, or anyoneelse attempting to communicate with the driver, can thus all make aninformed decision to not phone or text a person while driving. As aresult, the incidence of distracted driving can, in the aggregate, besignificantly reduced. The overall incidence of traffic accidents andfatalities will likely decrease with the use of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by reference to the followingdescription taken in conjunction with the accompanying drawings, whichillustrate specific, but non-exclusive, embodiments of the invention.

FIG. 1 is a diagram of a non-exclusive embodiment of a system forgenerating and delivering in driving and not driving push notificationsin accordance with a non-exclusive embodiment of the invention.

FIG. 2 is a block diagram of a non-exclusive embodiment of a mobilecommunication device in accordance with the principles of the presentinvention.

FIG. 3 is a diagram for ascertaining if a mobile communication device isin or not in a driving state in accordance with a non-exclusiveembodiment of the present invention.

FIGS. 4A through 4C illustrate several non-exclusive embodiments forgenerating and delivering push notifications in accordance with theprinciples of the present invention.

FIG. 5 is a flow diagram illustrating the steps of how a mobile devicegenerates in driving and not driving notifications in accordance withthe principles of the present invention.

FIG. 6 is a flow diagram illustrating the steps of how a cloud computinginfrastructure delivers driving and not driving push notifications totarget recipient(s) in accordance with the principles of the presentinvention.

FIG. 7 illustrates a sequence of steps for generating text pushnotifications in accordance with a non-exclusive embodiment of thepresent invention.

FIG. 8 illustrates a sequence of steps for generating email pushnotifications in accordance with a non-exclusive embodiment of theinvention.

FIG. 9 illustrates a sequence of steps for generating push notificationsreceived through a dashboard in accordance with another non-exclusiveembodiment of the invention.

FIG. 10 illustrates an exemplary dashboard for designating parties toreceive push notifications for a family of designated drivers inaccordance with one embodiment of the present invention.

It should be noted that like reference numbers refer to like elements inthe figures.

The above-listed figures are illustrative and are provided merely asexamples of embodiments for implementing the various principles andfeatures of the present invention. It should be understood that thefeatures and principles of the present invention may be implemented in avariety of other embodiments and the specific embodiments as illustratedin the Figures should in no way be construed as limiting the scope ofthe invention.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

The invention will now be described in detail with reference to variousembodiments thereof as illustrated in the accompanying drawings. In thefollowing description, specific details are set forth in order toprovide a thorough understanding of the invention. It will be apparent,however, to one skilled in the art, that the invention may be practicedwithout using some of the implementation details set forth herein. Itshould also be understood that well known operations have not beendescribed in detail in order to not unnecessarily obscure the invention.

In the present application, the term “driver” is intended to be broadlyconstrued to include any person in a vehicle. Consequently, as usedherein, the term is intended to not only mean the person behind thewheel and operating a vehicle, but also passengers in a vehicle as well.

Referring to FIG. 1, a system 10 for generating driver status pushnotifications delivered to target recipient(s) is illustrated. Thesystem 10 includes a mobile device 12, belonging to or otherwiseassociated with a person (not shown) either operating or a passenger ina vehicle 14. As explained in more detail below, the mobile device 12runs an application or “app” that is responsible for (i) determiningwhen the mobile device 12 is in a driving state or in a non-drivingstate and (ii) wirelessly reporting the current state information to acloud computing infrastructure 16. In response, the cloud computinginfrastructure 16 generates push notifications that indicate the currentdriving status or state (e.g., driving or not driving) of the person,which are delivered to one or more computing device(s) 18 belonging toone or more target recipient(s). By providing such notifications tointerested parties, such as family members, friends and/or co-workers,informed and proactive decisions to not call or text the person whiledriving can be made.

The push notifications thus provide timely, “peace of mind”, safetyinformation regarding the driving status of a person. For example,parents can be notified when a child is driving or is in a vehicle or afleet manager can be notified when an employee is driving. In eitherexample, the notified party can purposely delay making a phone call ortexting the person until after they have arrived at their destinationand are no longer driving. As a result, the person is not needlesslydistracted while driving, significantly improving road safety.

It should be noted, for the sake of simplicity, only a single mobiledevice 12 in a vehicle 14 is illustrated. It should be understood,however, that in actual embodiments, the app is intended to be installedand run on a multiplicity of mobile devices 12 belonging to a largenumber of people and the push notifications are intended to be deliveredto one or more target recipients associated with each driver. In thisway, the overall incidence of distracted driving can be significantlyreduced, improving road safety for all.

Referring to FIG. 2, a block diagram of a non-exclusive embodiment of anexemplary mobile device 12 in accordance with the principles of thepresent invention is shown. The mobile device 12 includes a controller20, such as a microprocessor, memory 22 such as RAM, ROM, and/or otherforms of persistent and/or non-persistent storage, output functions 24such as a touch-sensitive or a non-touch-sensitive display, inputfunctions 26 such as a virtual or actual keyboard, on/off switches,volume control buttons, vibration control buttons, etc., audio relatedfunctions 28 such as one or more speakers, microphones, audio alertgenerators, etc., a bi-directional antenna 30, coupled to adata/cellular interface 32 and a Bluetooth® interface 34, a GPS function36, an interface 38 for coupling the controller 20 to an OnboardDiagnostic System (OBD) on a vehicle 14, and an accelerometer 40. As theoperation of each of the elements 20 through 40 are well known, adetailed explanation is not provided herein. In various embodiments, themobile device 12 is a cell phone, tablet computer, or wearable computer,such as a smart watch. In addition, the GPS functionality 36 can beprovided by either a GPS application (e.g., Google® Maps) running on themobile device 12 and/or the onboard GPS functionality on the vehicle 14via the OBD interface 38 or any other location services provided by thecell phone or the telematics platform within the vehicle.

When a person has their mobile communication device 12 in a vehicle 14,it is typically in their pocket or purse, or placed within a designatedlocation, such as a dashboard console. As such, the mobile device 12 issubject to “ambient” motion when the vehicle 14 is driving. By ambientmotion, it is intended to mean the movement of the mobile device 12 inthe X, Y and/or Z directions relative to the vehicle 14 as the vehicleidles, accelerates, brakes, sways when turning, travels over bumps,potholes, and other surface imperfections, and other motions of thevehicle 14 while driving.

In accordance with the present invention, the controller 20 in mobiledevice 12 is configured to execute the aforementioned app, whichincludes computer code embedded in a computer readable medium such asmemory 32. As described in detail below, the app is configured tomeasure ambient motion patterns of the mobile device 12 and ascertainwhen the mobile device 12 is in or not in a vehicle 14 that is moving(i.e., travelling over a road surface). More specifically, the app isconfigured to:

(i) receive one or more sample signals from the accelerometer 40, whichare indicative of the motion of the mobile communication device 12;

(ii) ascertain when the mobile device 12 is in a driving state basedpatterns of ambient motion indicative of when the mobile device 12 is ina vehicle 14 that is driving over a road surface;

(iii) ascertain when the mobile device 12 is in a non driving statebased on motion patterns (or lack thereof) of the mobile device 12, forexample, while the device is held or in a pocket or purse while theperson is walking, or resting in a stationary position on a table ordesk; and

(iii) wirelessly transmit either the in driving state or non drivingstate status of the mobile device 12 to the cloud computinginfrastructure 16.

The app determines patterns of ambient motion of the mobile device 12from the sample signals generated by the accelerometer 40. When themotion patterns indicate that the vehicle 14 is in motion (e.g.,driving), then an in driving state determination is made. Otherwise, theapp assumes the mobile device 12 is in the non driving state.

During operation of the app, the accelerometer 40 periodically measuresand samples the ambient X, Y and Z motion of the mobile device 12 as thevehicle 14 is driving. From these samples, the app is able to determineif the vehicle 14 is in a driving state or not in accordance with thealgorithm described below.

Referring to FIG. 3, a diagram for ascertaining if mobile device 12 isin a driving state or not is shown. In this diagram, a plot of a numberof signal samples from the accelerometer 40 is provided over apredetermined period of time along the X axis. The magnitude of themeasured g-force of each signal sample is provided along the Y axis.

A g-force magnitude of 0.0 indicates that the mobile device 12 is atrest. A certain percentage of g-force readings in a positive range of(e.g., 0.1 through 0.3 g's) and a negative range of (e.g., −0.1 through−0.3 g's) in this example indicate typical readings of the accelerometer40 while in a vehicle 14 that is driving (i.e., the ambient motion ofthe mobile device 12 relative to the vehicle 14 while travelling over aroad surface). Further in this example, G-force readings havingmagnitude greater than the positive and negative range (e.g., +/−0.1 to+/−0.3) are indicative of acceleration of the mobile device 12 beyondwhat is normally expected to be measured while driving for a particularvehicle 14. For example, a mobile phone will typically be subject tog-forces greater than (+/−0.3 g's) when moved from a pocket or purse toa person's ear when answering an incoming telephone call or when themobile device 12 is in a person's pocket or purse while walking.Accordingly, such readings are typically used to make a determinationthat the mobile device 12 is not in the driving state.

In accordance with a non-exclusive embodiment, the algorithm used by theapp is configured to ascertain the number of signal samples having amagnitude within the positive and negative ranges (e.g., +/−0.1 to 0.3)over a predetermined period of time. Thereafter, the app determines ifthe mobile device 12 is in the driving state (i.e., the mobile device 12is in the vehicle 14 while driving) based on the number or percentage ofthe signal samples within the positive and negative ranges over thepredetermined period of time. For example, if 22 of 100 positive g-forcesignal samples are in the positive range and 24 of 100 negative g-forcesignal samples are in the negative range, then a total of 23% of the 200total readings fall in either of the two ranges. Based on thispercentage, the app can make a determination that the mobile device 12is in the driving state. In general, an approximate percentage range of18% to 25% of total sample points in either the positive or negativeranges over a predetermined period of time is indicative that the mobiledevice 12 is in a vehicle that is in motion.

Thus, in a non-exclusive embodiment, in a background process the app:(i) continually receives the sampling signals at the periodic samplinginterval from the accelerometer 40 and (ii) continually determines ifthe mobile device 12 is either in the driving state or the non drivingstate. In this manner, the app can continually provide the cloudcomputing infrastructure 16 with the current driving status of the ownerof the mobile device 12.

It should be understood that for the sake of simplicity, the diagram ofFIG. 3 plots acceleration of the mobile device 12 only in a singledirection (either X, Y or Z). In actual implementations, however, theacceleration readings in any or all of the X, Y and Z directions may beused. In general, g-reading in multiple directions provides moreaccuracy. In such embodiments, the number of signal readings in thepositive and negative ranges in each of the multiple directions may becombined together in determining if the mobile device 12 is in anundesirable or an acceptable motion state. Furthermore, theaforementioned range of (+/−0.1 to 0.3) g's, and the percentage range of18% to 25%, are also merely exemplary and in no way should be construedas limiting the scope of the present invention. In alternativeembodiments, different g-force ranges and ranges may be used. Theaforementioned ranges indicative of an “in driving state” may vary basedon a number of factors, such as the type of vehicle, the speed of thevehicle, road conditions, the smoothness (or lack thereof) quality ofthe road surface, etc. In order to take these factors into account, someembodiments of the app may include a “learning mode,” which calibratesfor the above factors in order to improve accuracy. For more details ofthe operation of the app, see commonly assigned co-pending U.S.Publication No. 2014/0342718 and U.S. Pat. No. 9,204,258, bothincorporated by reference herein for all purposes.

In the above-described embodiment, the app relies exclusively on thesignals generated by the accelerometer 40 provided on the mobile device12. In alternative embodiments, however, the app may also use othersignal generating devices, such as GPS device 36 and/or a vehicle speedsignal received via interface 38 from the OBD on the vehicle 14, eitherin lieu of or in cooperation with the signals received from theaccelerometer 40. In this latter embodiment, the app may use these othersignals to make a decision if the mobile device 12 is in the drivingstate, the not driving state, and alternatively, determine and trackstart and stop geographic locations.

In a non-exclusive embodiment, the cloud computing infrastructure 16 isresponsible for generating and delivering the in driving state and notdriving state push notifications to the target recipient(s) for a givenperson. In accordance with the present application, a number ofdifferent embodiments are illustrated in FIGS. 4A through 4C.

Referring to FIG. 4A, a notification list 50 for an exemplary personnamed “Jack Smith” is maintained within the cloud computinginfrastructure 16. In variations of this embodiment, the notificationlist 50 can be created in a number of different ways. For instance, JackSmith may access his contacts list on his mobile device 12 and designatecertain people to receive the push notifications, such as familymembers, friends, work supervisors, or other colleagues. Alternatively,the cloud computing infrastructure 16 may provide a dashboard portalthat allows the aforementioned people or any other interested party tocreate the notification list 50. For example, if Jack Smith is ateenager, the portal may be accessed by Jack's parents, who candesignate themselves and possibly others to receive push notificationsregarding Jack's driving status and/or driving destinations.Alternatively, if Jack is a fleet driver, then Jack's supervisor and/orother work colleagues may have access to the notification list 50 anddesignate the parties to receive push notifications.

In this illustrative example, the names Lori Aaron and Jen Casey aredesignated to receive the push notifications, while the names MattBarkely and Karen Walker are not. Accordingly, when the Jack's drivingstatus changes are received by the cloud computing infrastructure 16(e.g. in the driving state or not in the driving state), the designatedindividuals (Lori Aaron and Jen Casey) will receive push notifications,while the non-designated individuals (Matt Barkely and Karen Walker)will not.

Referring to the FIG. 4B embodiment, the cloud computing infrastructure16 is arranged to cooperate with other domains for the purpose ofidentifying and distributing push notifications. In this particularexample, Jack Smith's notification list 50 indicates that Lori Aaron andJen Casey are designated to receive push notifications. In the case ofLori Aaron, she happens to be a Google® user and maintains her contactinformation within the Google® cloud domain. Alternatively, Jen Caseyhappens to be a Yahoo® user and she maintains here contact informationin the Yahoo® cloud domain. With this arrangement, the cloud computinginfrastructure 16 shares Jack Smith's driving state (e.g., eitherdriving or not driving) with the Google® and Yahoo® domains, which inturn, update Jack's driving status in Lori Aaron's and Jen Casey'scontacts list respectively.

Referring to the FIG. 4C embodiment, another example of the cloudcomputing infrastructure 16 cooperating cross-platform with other cloudcommunication services is illustrated. In this particular example, JackSmith's driving state (either in driving or not driving) is shared withtwo popular communication platforms, “What's App®” and “Skype®”. In eachcase, the infrastructure of the communication service will notifyparties attempting to communicate with Jack of his driving status. Forexample, if a person wishes to send Jack a text message using What'sApp®, a push notification 54 is delivered to the person when Jack isselected as a message recipient. A similar push notification 54 is alsoprovided to a person wishing to call Jack using Skype®. In either case,the person is notified of Jack's current driving state. In this way, thecontacting party can make a conscious decision to not attempt tocommunicate with Jack until his status changes to not driving. It shouldbe noted that What's App® and Skype® are merely exemplary. Similarnotifications can be provided for any form of electronic communication,including but not limited to voice, text, SMS, email, or any othercommunication platform. This “presence” embodiment thus provides theability to provide near universal notifications if people are in thedriving mode or not. In yet another alternative embodiment, thecommunication platforms can be configured to not only discourage, butprevent, any communication with the driver while in the in drivingstatus. With this latter embodiment, incoming attempts to communicatewith a person while driving can be stopped altogether or delayed. Forexample, phone calls or other live communication, such as Skyping, canbe stopped by preventing the parties from establishing a synchronousconnection, meaning the parties are incapable of communicating over alive connection. With other types of messages, such as text messages,their delivery can purposely be delayed in the cloud until the status ofthe driver transitions from driving to not driving. In yet othervariations, the sender of a text message can be prevented from creatinga message intended for a driver in the driving state, or alternatively,the text message can be created, but either locally stored on thesending device or the cloud and then delivered out of storage only whenthe driver is no longer driving.

Referring to FIG. 5, a flow diagram 60 illustrating the steps how amobile device 12 generates in driving and not driving statusnotifications is illustrated.

In the initial step 62, the app is loaded onto a mobile device 12. As iswell known in the art, the app can be downloaded over a wired orwireless network from any source, such as but not limited to the Apple®App store, the Google® Play market, or any application distributionoutlet. Once an account is set up and the app is installed, theowner/user is identified and can be tracked through their mobile device12 running the app.

In the decision step 64, the app makes a determination of when themobile device 12 is in the driving state or not in the driving state. Aspreviously described, the app makes the determination by running abackground process for monitoring the motion patterns of the mobiledevice 12 relative to the motion of the vehicle 14 and/or receivinginput from the OBD interface 38 when in a vehicle 14.

In step 66, a “driving” notice is generated by the app and transmittedto the cloud computing infrastructure 16 when the app determines thatthe mobile device 12 is in a driving state. In alternative embodiments,the driving notice can be time/date stamped and the start geographiclocation can also be reported to the cloud computing infrastructure 16.

In decision 68, the app continues to run in the background, monitoringthe motion patterns of the mobile device 12.

In step 70, when it is determined that the mobile device 12 is no longerin the driving state, the app generates and transmits to the cloudcomputing infrastructure 16 a “not driving” notice.

In optional step 72, the app may also generate an “arrival atdestination” notice along with a geographic location and date/timestamp.

Thus, using the above steps, the current status (i.e., either in drivingor not driving) of the person associated with the mobile device 12 isreported to and known by the cloud computing infrastructure 16.

Referring to FIG. 6 a flow diagram 80 illustrating the steps how thecloud computing infrastructure 16 delivers push notifications to targetrecipient(s) is illustrated.

In the initial step 82, the cloud computing infrastructure 16 receiveseither the in driving or not driving state updates from the mobiledevice 12.

In step 84, the target recipient(s) are identified in response to thereceipt of a notice. As previously noted, the target recipient(s) aretypically identified by reading a notification list 50 associated withthe person using or owning the mobile device 12.

In step 86, a proper notification is generated. For example, an “indriving” notification is generated when a driving notice is received anda “not driving” notice is generated when a not driving notice isreceived from the mobile device 12.

In step 88, the notice is pushed to communication devices 18 of theidentified target recipient(s). In various embodiments, the pushnotifications can be delivered via messaging (email, text, SMS, voice,etc.) or by updating one or more dashboards accessible by the one ormore recipients respectively.

Finally, in optional step 90, different computing domains are notifiedregarding the driving status of the person associated with the mobiledevice 12 as discussed above with regard to the FIG. 4B and FIG. 4Cembodiments.

Thus, the flow chart of FIG. 6 illustrates the steps performed on thenetwork to receive driving status update notices and for delivering pushnotifications to target recipient(s).

Push Notification Examples

FIG. 7 illustrates a sequence of steps for generating text pushnotifications in accordance with a non-exclusive embodiment of thepresent invention. Specifically, from left to right, the app makes adetermination that a mobile device 12 that belongs to Jack Smith is in adriving state. In response to receiving an in-driving status, the cloudcomputing infrastructure 16 generates and delivers text messagenotifications to a designated party (e.g., Lori Aaron) of Jack'sdeparture and arrival.

FIG. 8 illustrates a sequence of steps for generating email pushnotifications in accordance with a non-exclusive embodiment of theinvention. This embodiment is essentially the same as that describedabove with respect to FIG. 7, except that email notifications of Jack'sdeparture and arrival are generated.

FIG. 9 illustrates a sequence of steps for generating push notificationsreceived through a dashboard in accordance with another non-exclusiveembodiment of the invention. Again, this embodiment is essentially thesame as the previous two, except a web view dashboard accessible by thedesignated party (e.g., Lori Aaron) is updated upon Jack's departure andarrival as well as the current drive status of the driver as noted bythe “Currently Driving” status field.

It should be noted for the sake of simplicity, only one party isdesignated to receive in driving or not driving status notifications ineach of the FIGS. 7-9 examples. It should be understood, however, thatin actual embodiments, the number of parties designated to receive suchnotifications may vary from one to many. In addition, the driving statusof many drivers may simultaneously be tracked. As a result, the presentinvention as described herein has the potential of significantlyreducing the incidence of distracted driving.

Dashboard Example for Creating Family View

Referring to FIG. 10, an exemplary dashboard 100 for designating partiesto receive push notifications for a family of drivers is shown. In thisparticular example, the dashboard 100 includes a data entry field 102for naming the family view (web view), a data entry field 104 for namingthe drivers of the family visible within the dashboard. Within this dataentry field 104, sub-fields are provided for defining the driver(s) name106, designating if each named drivers is visible or not visible in thefamily view 108, and sub-fields 110 for designating if notifications forthe last known location for each driver is enabled or disabled. Finally,a data entry field 112 is provided for designating the people that canaccess the family view. Within this data entry field 112, the peoplethat can access the family view are defined. When the family view is“shared,” a web view (URL link) is then sent specifically to thosepeople designated to access the family view. It is important to notethis family view can include anyone with a mobile number and that therecipient needs no special software or app installed to view the statusof the driver(s) visible in the family view. Thus by viewing thedashboard, family members and other designated individuals can makeproactive decisions to contact or not contact family members whiledriving.

In the above example, a dashboard is used by a family. It should beunderstood that a similar dashboard could be used by a company or otherorganization have a fleet of drivers. For example, a company name can beprovided in data entry field 102. The drivers to be visible and trackedare listed in data entry field 104, along with drivers names in field106, their visibility in family view field 108, and whether or not thelast known location functionality for each driver is enabled or not insub-fields 110. Finally, the members of the company, such as fleetmanagers, administrators, dispatchers, etc. can be designated as personshaving access to the dashboard for viewing driver status. The dashboardthus allows fleet managers, administrators and/or dispatchers to trackdrivers and make proactive decisions when to contact or not contact thedrivers depending on their location and/or driving status.

It should be understood that the aforementioned embodiments can be usedfor a multitude of drivers and push notifications can be delivered to awide range of designated contacts. In this way, driver statusinformation can be widely disseminated among the general public,resulting in far less instances of distracted driver and safer drivingconditions.

Alternative Embodiments

In yet other embodiments, notifications can be relabeled as “drivingstarted” and “driving ended” instead of merely providing an in drivingstatus or not driving status. Such notices may be considered a more“user-friendly” alternative in certain circumstances.

In yet other embodiments, the system and method of the present inventioncan be further enhanced or modified to recognize a driver's route basedon past driving history and make a reasonable estimation as to thedriver's destination and estimated time of arrival. This embodiment isimplemented by configuring the app to collect data related to start andend points of each drive. Based on the location of the vehicle duringthe drive, certain inferences about the route can be made and matchedwith previous end points of this driver. Thus, based on the currentlocation of the vehicle, and the assumed end point of the current drive,the app can calculate or ping a navigation API service to calculate theremaining time to the destination (i.e., the Estimated Time of Arrivalor “ETA”). In various alternatives of this embodiment, the ETAnotifications can be continually generated at periodic intervals (e.g.,every minute, every 5 minutes, 10 minutes, etc.), or alternatively, onlywhen a person wishes to contact a driver. In the later example, a realtime ETA calculation can be made and delivered to the person wishing tocontact the driver. Regardless of the type of notification, knowing theETA of the driver will also help to discourage the non-driver frommaking a dangerous call or texting during the drive if they know howlong they will have to wait. In yet other embodiments, the app can beconfigured to operate with a GPS application or other GPS services on auser's mobile device to calculate and generate such ETA notifications.

Although many of the components and processes are described above in thesingular for convenience, it will be appreciated by one of skill in theart that multiple components and repeated processes can also be used topractice the techniques of the system and method described herein.Further, while the invention has been particularly shown and describedwith reference to specific embodiments thereof, it will be understood bythose skilled in the art that changes in the form and details of thedisclosed embodiments may be made without departing from the spirit orscope of the invention. For example, embodiments of the invention may beemployed with a variety of components and should not be restricted tothe ones mentioned above. This would include embedding the driver statusinvention within any other app or device feature including commonlyprovided mobile device phone and VoIP apps. It is therefore intendedthat the invention be interpreted to include all variations andequivalents that fall within the true spirit and scope of the invention.

What is claimed is:
 1. A method, comprising: detecting when a mobiledevice associated with a person is in a driving state while in a vehiclethat is in motion; and delivering a push notification notifying one ormore target recipient(s) that the person associated with the mobiledevice is in the driving state, the push notification provided todiscourage the one or more target recipient(s) from texting or callingthe person while in the driving state.